Partie 1 : Introduction

1. Avant-propos

1.1. Sur ce document

1.1.1. A qui est destiné ce document?

Les étudiants qui découvrent le langage, mes collègues enseignants qui cherchent un document de support à leur cours et d’exercice accessible, et … moi-même (pour organiser mes notes diverses)!

1.1.2. A qui n’est-il pas destiné?

Si vous appartenez à l’une de ces catégories, ce livre n’est pas pour vous :

  • vous cherchez un livre de référence (pour cela, même s’il est en anglais, je conseille [FMS])

  • vous voulez vous perfectionner (ce livre n’est qu’une introduction)

  • vous souhaitez préparer la certification de l’OMG (mieux vaut vous plonger dans la spécification [SysML])

1.1.3. Historique

Ce document est la compilation de plusieurs années d’enseignement de SysML depuis 2007, que ce soit :

Vous trouverez en référence (cf. [refs]) les ouvrages et autres documents utilisés.

Je tiens à remercier mes collègues qui m’ont aidé dans mon entreprise :

1.2. Sur l’auteur

  • Professeur à l’Univesité de Toulouse

  • Co-fondateur de l’association SysML-France en 2009

  • Membre du comité éditorial de la revue Software and System Modeling journal depuis sa création en 2002

  • Membre du Steering Committee de la conférence ACM/IEEE MODELS depuis 2008

  • Enseignant en modélisation depuis 1995

  • Chef du département informatique de l’IUT de Blagnac de 2009 à 2012

  • Co-responsable de l’axe Systèmes Ambiants de l’IRIT

  • Marié, une (merveilleuse) fille

1.3. Comment lire ce document?

1.3.1. Version électronique

Ce document a été réalisé de manière à être lu de préférence dans sa version électronique, ce qui permet de naviguer entre les références et les renvois interactivement, de consulter directement les documents référencés par une URL, etc.

Note

Si vous lisez la version papier de ce document, ces liens clickables ne vous servent à rien, mais n’hésitez pas à en consulter la version électronique!

1.3.2. Conventions typographiques

J’ai utilisé un certain nombre de conventions personnelles pour rendre ce document le plus agréable à lire et le plus utile possible, grâce notamment à la puissance d’AsciiDoc :

  • des mises en formes particulières (e.g., NomDeBloc pour un élément de modèle),

  • des références bibliographiques, présentées en fin de document (cf. [refs]),

  • tous les flottants (figures, tableaux) sont listés à la suite de la table des matière,

  • les termes anglais (souvent incontournables) sont repérés en italique, non pas pour indiquer qu’il s’agit d’un mot anglais, mais pour indiquer au lecteur que nous employons volontairement ces termes (e.g., Requirements).

Les figures, sauf mention contraire, ont été réalisées avec l’outil TOPCASED en français. Le titre des figures indique (entre parenthèses) un R pour les figures issues de Rhapsody et un UK pour les figures en anglais. Pour les conventions (de nommage notamment), cf. [conventions].

Note

Les notes comme celles-ci sont utilisées pour indiquer des éléments intéressant pour la majorité des lecteurs.

Caution

Ces notes indiquent des points importants qui réclament votre attention.

Tip

Celles-ci concernent en général des points de détail et permettent "d’aller plus loin".

Note
Définition : Exemple (OMG SysML v1.3, p. 152)

Ces notes concernent des définitions tirées de la spécification SysML et sont donc précisément référencées.

1.3.3. Pourquoi parler de "document"?

Parce que j’ignore la version que vous êtes en train de lire. A partir de l’original, plusieurs versions ont été générées grâce à AsciiDoc :

  • pour le web (nous utilisons à l’IUT de Blagnac l’excellent Moodle) au format html

  • pour présentation (en amphi par exemple) au format slidy ou deck.js

  • pour impression au format pdf (bien que bien sûr nous vous recommandons l’achat du livre)

  • pour lire au format Kindle (bientôt!)

1.3.4. Utilisation et autres mentions légales

Dernière MAJ : 25/06/2013 - 18:48:34 CEST
Document généré par Jean-Michel Bruel via AsciiDoc (version 8.6.8) de Stuart Rackham. La version présentation a été générée en utilisant W3C HTML Slidy © de Dave Raggett, amélioré par Jean-Michel Inglebert. Pour l’instant ce document est libre d’utilisation et géré par la Licence Creative Commons. Licence Creative  Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.

N’hésitez pas à m’envoyer vos remarques en tout genre en m'écrivant ici.

1.4. Méthode pour cet ouvrage

C’est à l’heure du commencement qu’il faut tout particulièrement veiller à ce que les équilibres soient précis.

Extrait du Manuel de Muad’Dib
— Princesse Irulan

Mon approche pédagogique repose sur quelques principes, que j’ai essayé de mettre en oeuvre dans cet ouvrage :

La répétition

Par exemple certains diagrammes sont abordés plusieurs fois (comme le diagramme paramétrique). Le lecteur pourra avoir une impression de redite par moment. Sauf erreur de ma part (toujours possible!), c’est volontaire. En général les répétitions vont en niveau de précision, de détails et de complexité croissant. Ces répétitions sont limitées dans la version livre de cet ouvrage (car toute longueur inutile a un coût dans ce cas).

L’illustration

Dans la mesure du possible, j’essaye de donner des exemples aux principes énoncés. Vous trouverez donc plus d’exemples que de définitions.

Le référencement

Les définitions ou autres affirmations sont tirées d’ouvrages de référence généralement citées.

La "carte de base"

J’aime réaliser une "carte"
[voir aussi le concept de Mind Maps.]
qui sert à "placer" les différents concepts abordés. Il me semble que cela permet aux étudiants de raccrocher les nouveaux concepts aux précédents.

Aucune connaissance particulière d’UML n’est nécessaire, même si j’y fais référence à plusieurs endroits pour les étudiants qui connaissent cette notation (quasiment enseignée partout maintenant comme langage de modélisation). Il s’agit d’un parti pris prenant en compte plusieurs points :

  • La plupart des ingénieurs systèmes ne connaissent pas UML.

  • Les étudiants de STI2D ne connaissent pas UML et sont pourtant formés à SysML.

  • Ceux qui connaissent UML auront sûrement plaisir à retrouver les bases.

2. C’est quoi SysML?

Si vous ne deviez lire qu’un seul chapitre, voilà ce qu’il faudrait retenir.

2.1. Fiche d’identité

  • Date de naissance non officielle : 2001!

  • Première spécification adoptée à l’OMG : 19 septembre 2007

  • Version actuelle : 1.3 (12/06/2012)

  • Paternité : OMG/UML + INCOSE

  • Auteurs principaux :

    • Conrad Bock

    • Cris Kobryn

    • Sanford Friedenthal

2.2. SysML, c’est…

Un ensemble de 9 types de diagrammes
  • Diagrammes structuraux

    • Diagrammes de définition de blocs (bdd)

    • Diagrammes internes de blocs (ibd)

    • Diagrammes paramétriques (par)

    • Diagrammes de packages (pkg)

  • Diagrammes comportementaux

    • Diagrammes de séquence (sd)

    • Diagrammes d’activité (act)

    • Diagrammes de cas d’utilisation (uc)

    • Diagrammes d'états (stm)

  • Diagramme d’exigence (req)

Un profil UML

C’est à dire une extension de cette notation, un ensemble de nouveaux concepts et éléments qui sont définis à partir des éléments de base d’UML. Un exemple : le bloc qui n’est qu’une redéfinition de la classe.

Une notation

Une notation de plus en plus enseignée et connue et qui servira donc de plus en plus de référence à la modélisation des systèmes.

2.3. SysML, ce n’est pas…

Une méthode

En effet, contrairement à ce que beaucoup pensent en l’abordant, SysML ne propose pas de démarche particulière de développement de système. C’est à la fois sa force (votre méthode existante pourra continuer à être utilisée) comme sa faiblesse car cette absence de guide méthodologique fait souvent défaut à son utilisation.

Un outil

Nous verrons en effet que SysML ne fait que ce qu’on veut bien en faire. Comme tout langage il est limité dans son pouvoir d’expression, mais surtout il reste une simple notation qu’il convient d’utiliser avec des outils et des démarches associées.

Un raton laveur

C’est juste pour voir ceux qui suivent.

2.4. Références et liens utiles

Vous trouverez en fin d’ouvrage un ensemble de liens utiles (cf. [liens]) et de références (cf. [refs]). Sinon, vous pouvez aussi constatez les évolutions de l’intérêt pour SysML grâce aux "trends". Voici les dernières tendances au moment où nous écrivons ces lignes
[Ou bien utilisez les URLs comme http://www.google.fr/trends/explore#q=sysml.]
:

Figure 1. Trends : Twitter
Note

On y voit les journées SysML 2012 (Toulouse et Mulhouse).

Figure 2. Trends : Google (Carte)
Figure 3. Trends : Google (Liste)
Figure 4. Effet SysML-France?

À noter également que l’OMG a réalisé en 2009 une enquête sur l’utilisation de SysML
[http://www.omgsysml.org/SysML_2009_RFI_Response_Summary-bone-cloutier.pdf]
dont voici deux extraits :

Figure 5. Principaux domaines d’utilisation
Figure 6. Diagrammes les plus utilisés

3. À propos du Bac STI2D

Si vous utilisez cet ouvrage dans le cadre du bac STI2D (Sciences et Technologies de l’Industrie et du Développement Durable) qui a introduit depuis 2011 la notation SysML au programme, nous donnons ici des conseils sur l’utilisation de ce cours
[Je remercie au passage les collègues de Lycée rencontrés dans le cadre de SysML-France pour nos fructueuses discussions à ce sujet.]
.

L’objectif en STI2D n’est pas de former des spécialistes de SysML mais de permettre à tous d’apprendre une notation pour la modélisation de système qui se veut universelle. Il ne faut donc pas viser la complétude ou même demander trop de détails. La logique de la démarche de modélisation et l’importance de la communication devront primer.

Note

A l’heure où nous écrivons ces lignes, il est également prévu de l’enseigner en classe prépa dès 2013.

3.1. Utilisation pratique

Cet ouvrage est tout à fait utilisable dans le cadre des cours dispensés en STI2D. Seul un sous-ensemble des diagrammes de SysML a été retenu. Les élèves et les enseignants du bac STI2D pourront trouver dans ce document des éléments utiles sur ces diagrammes :

  • diagramme des exigences (cf. [reqs])

  • diagramme des cas d’utilisation (cf. [usecase])

  • diagramme de séquences (cf. [seq])

  • diagramme d'états (cf. [stm])

  • diagramme de définition de blocs (cf. [bddsec])

  • diagramme de blocs internes (cf. [ibd])

Ces 6 diagrammes sont tous traités dans cet ouvrage à un niveau qui devrait correspondre à l’utilisation qui en est faite en STI2D.

Ces 6 diagrammes servent trois objectifs principaux inscrits au programme et dont les élèves pourront également trouver des éléments de réflexion :

3.2. Pour aller plus loin

Les questions et exercices de fin de chapitres de la partie notation seront peut-être d’un niveau plus avancé pour servir véritablement d’exercices, mais pourront amener à une réflexion encadrée par l’enseignant.

Un blog récent recense les supports en liens avec STI2D : http://www.scoop.it/t/formation-sysml-sti2d.

4. Un exemple fil rouge

L’exemple de système qui sera modélisé tout au long de ce livre en guise d’exemple est l’exemple d’un système de gestion et de supervision de crise. Les détails sont donnés en annexe (cf. Annexes).

Il existe un certain nombre d’autres exemple complets :

  • Le radio-réveil de Pascal Roques [Roques2010], un exemple simpliste mais didactique qui a le mérite d'être déjà connu des modeleurs UML qui ont lu ses livres.

  • Le distilleur de [FMS], un exemple très complet et lui aussi très connu car beaucoup utilisé dans les tutoriels issus de l’OMG.

  • Le pacemaker de [SeeBook2012]
    [Nous avons réalisé le chapitre d’introduction à SysML de cet ouvrage.]
    , un exemple très récent et dont l’avantage est d'être traité selon plusieurs approches différentes et complémentaires (SysML, AADL et MARTE).

Les exemples complets ont le mérite de donner une vue d’ensemble des liens qui peuvent exister entre les différents diagrammes. On peut y voir comment ces diagrammes sont complémentaires les uns des autres. Ils sont en général plus réalistes que les diagrammes utilisés pour illustrer tel ou tel concept de la notation.

4.1. Enoncé

Tip

Cette étude de cas est tirée de Kienzle2010

Le système CMS (crash management system) est un système distribué de gestion d’accidents qui est responsable de la coordination et de la communication entre un coordinateur présent dans une caserne de pompiers (appelé FSC pour Fire Station Coordinator) et un autre présent dans un poste de police (appelé PSC pour Police Station Coordinator) afin de gérer une crise dans un délai raisonnable.

images/CMS.png
Figure 7. Le système CMS

La communication interne entre les membres de la police (y compris le PSC) est en dehors du domaine qui nous intéresse ici (la gestion de crise). La même hypothèse s’applique aux communications internes ou avec des acteurs externes côté pompiers (y compris le FSC). Les informations concernant la crise ainsi que tout ce qui a trait aux tâches des coordinateurs sont mises à jour et maintenues pendant et après la crise.

Il n’existe pas de base de données centrale; caserne de pompiers et police ayant leur base de données respectives distinctes et seulement accessible aux autre à travers le système CMS. Chaque processus de coordination est donc en charge de l’ajout et la mise à jour des informations dans sa base de données respective.

CMS commence à fonctionner au moment où une crise donnée a été détectée et déclarée à la fois à la caserne de pompiers et au poste de police.

Toutes les caractéristiques des différents acteurs sont détaillées ci-dessous.

4.1.1. Coordinateur des pompiers (FSC)

Un FSC maintient le contrôle sur une situation de crise en communiquant avec le coordinateur du poste de police (PSC) ainsi que les pompiers.

Pour atteindre ses objectifs, les responsabilités d’un FSC sont les suivantes :

  • de déterminer où, quand et combien de camions de pompiers à envoyer,

  • de communiquer avec le PSC pour se présenter,

  • de garder le PSC informé en ce qui concerne la crise,

  • de proposer une stratégie pour traiter la crise,

  • parvenir à un accord avec le PSC sur la façon de procéder,

  • de recevoir des mises à jour concernant la crise côté pompiers, et

  • de rassembler et de diffuser des informations actualisées aux pompiers.

4.1.2. Pompiers

Un pompier agit sur ordres reçus du FSC et des fait des rapports au FSC. Par ailleurs, un pompier communique avec d’autres pompiers, des victimes et des témoins.

Les responsabilités d’un pompier sont les suivantes :

  • recevoir des demandes pour aller/revenir sur les lieux de la crise,

  • signaler sa position au FSC,

  • signaler les conditions de la crise au FSC et à tous les pompiers, et

  • communiquer avec les victimes et les témoins.

4.1.3. Coordinateur du poste de police (PSC)

Pour atteindre ses objectifs, un PSC effectue les mêmes activités que le FSC.

4.1.4. Agents de police

Les agents de police agissent sur ordres reçus du PSC. En outre, un agent de police communique avec d’autres policiers, des victimes et des témoins. Pour atteindre ses objectifs, un agent de police exerce les mêmes activités qu’un pompier en termes de communication avec son coordinateur.

4.1.5. Victimes (de la crise)

Une victime a été touchée par la crise et peut communiquer avec les policiers et les pompiers. Les responsabilités d’une victime sont :

  • de fournir des informations liées à la crise

  • de suivre les instructions de pompiers et de policiers.

4.1.6. Témoins (de la crise)

Un témoin a observé la crise et communique avec les policiers et les pompiers. Les responsabilités d’un témoin sont les suivantes :

  • de fournir des informations aux pompiers et les policiers, et

  • de suivre les instructions de pompiers et de policiers.

4.1.7. Informations complémentaires

Pour enrichir vos modèles, vous pouvez incorporer certains des besoins non-fonctionnels décrits ci-dessous.

Le système de gestion de crise doit montrer les suivants propriétés non-fonctionnelles :

Caution

La traduction a été principalement obtenue automatiquement, alors n’hésitez pas en cas de doutes à poser des questions!

Disponibilité
  • Le système doit être en opération 24 heures par jour, tous les jours, sans interruption, pendant toute l’année, sauf pour un temps d’arrêt maximal de 2 heures tous les 30 jours pour la maintenance.

  • Le système doit récupérer dans un maximum de 30 secondes en cas d'échec.

  • L’entretien doit être reportée ou interrompue quand une crise est imminente sans affecter les capacités des systèmes.

Fiabilité
  • Le système ne doit pas dépasser un taux d'échec maximum de 0,001%.

  • Les unités mobiles sont en mesure de communiquer avec d’autres unités sur le site crise et le centre de contrôle, indépendamment des conditions d’emplacement, le terrain et la météo.

Persistance
  • Le système doit permettre le stockage, la mise à jour et l’accès à l’information suivante sur les crises : type de crise, l’emplacement de la crise, rapport d’un témoin, emplacement du témoin, les données concernant les témoins, la durée de la crise, les ressources déployées, les victimes civiles, les stratégies utilisées, l’emplacement des équipes de secours sur la crise, journal des communications, et des décisions.

  • Le système doit permettre le stockage, la mise à jour et l’accès à l’information suivante sur les ressources disponibles et déployés (à la fois en interne et en externe) : type de ressources (humaines ou équipement), la capacité, l'équipe de sauvetage, l’emplacement, l’heure estimée d’arrivée (ETA) sur le site crise.

  • Le système doit permettre le stockage, la mise à jour et l’accès à l’information suivante sur les stratégies de sortie de crise : type de crise, étapes pour résoudre la crise, la configuration des missions nécessaires, des liens vers d’autres stratégies, applications aux crises précédentes, et le taux de succès.

Sécurité
  • Le système doit définir des politiques d’accès pour les différentes catégories d’utilisateurs. La politique d’accès doit décrire les éléments et informations de chaque acteur peut ajouter, accéder et mettre à jour les informations.

  • Le système doit authentifier les utilisateurs sur la base des politiques d’accès lors de leur premier accès pour accéder aux éléments d’informations. Si un utilisateur reste inactif pendant 30 minutes ou plus, le système doit les obliger à se ré-authentifier.

  • Toutes les communications dans le système doit utiliser des canaux sécurisés conformes avec le cryptage AES-128 standard.

Mobilité
  • Les ressources de secours doivent pouvoir accéder à l’information sur les mouvements.

  • Le système fournit des informations de localisation utiles pour économiser les ressources.

  • Les ressources de secours doivent communiquer leur emplacement au centre de contrôle.

  • Le système doit avoir accès à des cartes détaillées, des données de terrain et les conditions météorologiques pour l’emplacement de crise et les routes qui y mènent.

Sécurité
  • Le système doit surveiller les émissions provenant du site crise pour déterminer les distances de fonctionnement sûres pour les ressources de sauvetage.

  • Le système doit surveiller les conditions météorologiques et le terrain sur le site de crise pour assurer la sécurité et le retrait des moyens de secours, et l'évacuation de civils, et les victimes.

  • Le système détermine un périmètre pour le site crise pour assurer la sécurité des civils et l'évacuation des victimes à une distance sûre.

  • Le système surveille les activités criminelles pour assurer la sécurité des moyens de secours, des civils et des blessés.

  • La sécurité du personnel de secours doit avoir la priorité absolue pour le système.

Adaptabilité
  • Le système doit recommander ou solliciter des ressources alternatives en cas d’indisponibilité ou l’insuffisance de ressources appropriées.

  • Le système doit être en mesure d’utiliser les canaux de communication de rechange en cas d’indisponibilité ou l’insuffisance des moyens existants.

  • Le système doit être en mesure de maintenir une communication efficace dans les zones de perturbation ou de bruit élevé sur le site crise.

Précision
  • Le système doit avoir accès aux données de la carte, le terrain et les conditions météorologiques avec une précision de 99%.

  • Le système doit fournir des informations à jour pour sauver les ressources.

  • Le système doit enregistrer des données sur la réception sans modifications.

  • La communication entre le système et les ressources de sauvetage doit avoir un facteur de détérioration maximum de 0,0001 pour 1000 km

Partie 2 : Ingénierie système

1. Introduction

La matrice qui nous servira de "carte de base" pour placer les activités ou les modèles, sera celle-ci :

Table 1. La carte de base
Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

1.1. Points de vue

Dans un axe horizontal, j’ai différencié quatre grands points de vue :

Requirements

Les exigences et leur prises en compte sont un éléments critique pour le succès du développement du système. Sans explorer l’ensemble des activités d’ingénierie système (ce qui nécessiterait tout un volume du type de [reqs]) nous insisterons beaucoup sur cet aspect qui est souvent à l’origine de l’intérêt de SysML.

Structure

La description de l’architecture et des éléments constitutifs du système, avec les blocs, leurs relations, organisations internes, etc. constituera un point de vue important. C’est souvent la partie de SysML qui pose le moins de problème aux débutants.

Comportement

Le comportement d’un système est du point de vue de l’utilisateur final beaucoup plus important que la structure elle-même. C’est la partie qu’il est la plus à même d’exprimer, de comprendre (vos modèles) et de valider.

Transverse

Un certains nombre de concepts sont transverses aux trois points de vue précédents. Il s’agira principalement de parler de cohérence entre les phases de développement ou entre les points de vue.

1.2. Phase de développement

Dans un axe vertical, j’ai différencié quatre grandes phases du cycle de vie du développement :

Organisation

Une étape indépendante du type de cycle de développement envisagé (en V, agile, etc.) mais qui concerne la mise en place d’un cadre de travail qui permette un développement de qualité (outils, éditeurs, gestionnaire de version, de tâches, etc.)

Analyse

Cette phase vise plutôt à examiner le domaine du problème. Elle se focalise sur les cahiers des charges et les exigences. L’analyse débouche sur un dossier d’analyse qui décrit les grandes lignes (cas d’utilisation, architecture principale) du système.

Conception

Cette phase vise plutôt à examiner le domaine de la solution. Elle débouche sur un dossier de conception qui décrit les détails conceptuels de la solution envisagée (structure détaillée, comportement, etc.)

Implémentation

Cette phase traite des développements finaux (construction ou approvisionnement en matériel, développement de codes, etc.).

2. Différence avec l’ingénierie logicielle

Enseignant en informatique, je me retrouve souvent à enseigner SysML à des informaticiens. D’où ce petit exposé sur mon opinion de la différence entre les deux "mondes".

2.1. Une ingénierie plus ancienne

Que ce soit généralement en terme de cycle de développement ou historiquement, l’Ingénierie Système arrive avant l’Ingénierie Logicielle. Les ingénieurs systèmes ont donc une longue expérience et des pratiques bien ancrées.

2.2. Des systèmes plus complexes

On parle de système complexe lorsque l’on a affaire à :

  • un ensemble d'éléments humains et matériels en relation avec :

    • de nombreux éléments technologiques (Informatique, Hydraulique, Electronique, …)

    • intégrés pour fournir des services (finalité du système) en fonction de leur environnement

    • interagissant entre eux et avec leur environnement

Figure 8. Un système complexe

On parle aussi de Système de systèmes quand un système :

  • doit gérer les interactions entre ses parties (ou composantes)

  • assure un comportement prévu à l’avance

  • gère les comportements (de l’environnement) inatendus

Figure 9. Un système de système

2.3. Différents types d’analyse

Toute la question que l’Ingénierie Système cherche à résoudre est : comment passer des exigences au système de la façon la plus efficace possible.

Des reqs au système
Figure 10. Des exigences au système

Pour cela l’Ingénierie Système est découpée en plusieurs analyses, chacune avec un but bien particulier :

Des reqs au système
Figure 11. Analyse Fonctionnelle et/ou Comportementale
Des reqs au système
Figure 12. Analyse Structurelle
Des reqs au système
Figure 13. Analyse de performance
Des reqs au système
Figure 14. Analyses spécifiques

Pour arriver à combler le gap entre le système à développer et ses spécifications.

Des reqs au système
Figure 15. Des exigences au système

3. Normes et standards

Il existe un grand nombre de standards en Ingénierie Système. Cette section fera (bientôt) une revue de ces différents standards et organismes et de leur utilisation (IEEE, EIA, ISO, certification, NASA, INCOSE, AFIS, …).

Enfin, citons un rapport de 2010, le Rapport Potier, qui présente l'état des logiciels embarqués et qui sera utiles à ceux qui s’intéressent aux verrous technologiques liés à ce domaine.

L’Ingénierie Système génère beaucoup de documentation. Les processus de certification (par exemple dans l’aéronautique) sont encore basés sur des documents textuels.

4. Des documents aux modèles

Vue la complexité grandissante des systèmes, petit à petit cette ingénierie tente de passer d’une ingénierie centrée documents à une ingénierie centrée modèles. D’où l’importance de se poser la question des notations et langages pour réaliser et communiquer avec ces modèles (cf. [Notation]).

5. Les exigences

L’ingénierie des exigences est d’une importance capitale en Ingénierie Système. Nous renvoyons pour l’instant le lecteur au cours de Master qui précède ce cours.

Figure 16. 300 corps de métiers sont parfois présents sur un chantier
Joke
Illustration: Humour (taken from here)

6. L’architecture du système

Liens avec AADL, …

7. Le comportement du système

Liens avec la V&V

8. Méthodes et démarches

Everything should be made as simple as possible, but not simpler.

— Albert Einstein

SysML n’est pas une méthode. En effet aucune démarche n’est imposée pour l’utilisation des diagrammes, l’ordre logique dans lesquels il vaut mieux les réaliser, etc. La spécification ne porte que sur la notation elle-même. D’où le pluriel dans le titre de cette section : il existe presque autant de méthodes que d’entreprise développant des systèmes. Nous nous contenterons de donner ici quelques heuristiques (cf. [methodo] pour la présentation de quelques méthodes bien identifiées) :

Heuristique : Approche itérative

Un diagramme ne doit pas être considéré comme définitif. Il peut être complété alors que l’on traite un autre aspect de la modélisation (exemple classique : ajout d’un nouveau bloc lors de la réalisation d’un diagramme de séquence). Quelque soit la démarche adoptée elle doit être itérative et permettre de revenir sur les premières étapes.

Heuristique : Niveau d’abstraction

Bien intégrer les niveaux d’abstraction dans votre démarche. SysML possède certaines constructions pour formaliser cet aspect (Packages par exemple). Nous matérialisons cet aspect par la partie verticale de la matrice (cf. [Matrice]).

Heuristique : Tous les diagrammes ne sont pas utiles

N’essayez pas de réaliser tous les diagrammes possibles pour votre système. Réalisez uniquement ceux qui sont utiles à votre cas particulier.

Partie 3 : La notation SysML

1. Pourquoi une nouvelle notation

A good notation has subtlety and suggestiveness which at times makes it almost seem like a live teacher.

The World of Mathematics (1956)
— Bertrand Russell

Il existe une notation qui se veut "unifiée" pour les modèles : UML. Néanmoins cette notation est peu adaptée pour l’Ingénierie Système :

  • UML 1.x était complètement inadaptée :

    • Principalement pour les systèmes d’information

    • Peu de liens entre les diagrammes

    • Peu de liens entre les modèles et les exigences

  • UML 2.x n’est pas beaucoup mieux si ce n’est :

    • Implication des ingénieurs systèmes pour sa définition

    • Introduction du diagramme de structure composite

En conclusion UML est une bonne base :

  • Standard De facto en génie logiciel

  • Fournit beaucoup de concepts utiles pour décrire des systèmes (même complexes)

  • Stable et extensible (grâce notamment au mécanisme de profile)

  • Beaucoup d’outils disponibles

Mais…

  • Manque de certains concepts clés d’Ingénierie Système

  • Vocabulaire beaucoup trop « software » pour être utilisé par les ingénieurs systèmes (concept de classe ou d'héritage par exemple)

  • Trop de diagrammes (13 sortes)

2. Introduction à SysML

2.1. Fiche d’identité

Voici à quoi pourrait ressembler la fiche d’identité de SysML :

  • Date de naissance non officielle : 2001!

  • Première spécification adoptée à l’OMG : 19 septembre 2007

  • Version actuelle : 1.3 (12/06/2012)

  • Paternité : OMG/UML + INCOSE

  • Auteurs principaux :

    • Conrad Bock

    • Cris Kobryn

    • Sanford Friedenthal

2.2. Différence avec UML

La figure suivante, tirée de la spécification, résume bien les liens entre SysML et UML, à savoir que SysML reprend une partie seulement des concepts d’UML (appelée UML4SysML) en y ajoutant des concepts nouveaux.

images/diff.png
Figure 17. Liens entre UML et SysML

2.3. Qui est "derrière"?

Industrie

American Systems, BAE Systems, Boeing, Deere & Company, EADS Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, NIST, Northrop Grumman, oose.de, Raytheon, Thales, …

Vendeurs d’outils

Artisan, EmbeddedPlus, Gentleware, IBM, Mentor Graphics, PivotPoint Technology, Sparx Systems, Vitech, …

Autres organisations

AP-233, INCOSE, Georgia Institute of Technology, AFIS, …

Tip

La liste complète des membres de l’OMG est accessible à l’URL : http://www.omg.org/cgi-bin/apps/membersearch.pl

2.4. Organisation des différents diagrammes

images/Figure4-1.png
Figure 18. Les 9 diagrammes SysML et leur lien avec UML
images/Figure4-1-bis.png
Figure 19. Version abrégée des diagrammes
Note
Définition : Types de diagrammes (OMG SysML v1.3, p. 170)

SysML diagram kinds should have the following names or (abbreviations) as part of the heading…

2.5. Différence entre modèle et dessin

SysML n’est pas une palette de dessins et d'éléments de base servant à faire des diagrammes. Il existe une représentation graphique des éléments modélisés en SysML. Elle est importante car elle permet de communiquer visuellement sur le système en développement, mais du point de vue du concepteur, c’est le modèle qui importe le plus.

C’est pourquoi nous vous recommandons de ne jamais "dessiner" des diagrammes SysML
[Sauf bien sûr au brouillon ou sur un tableau, notamment quand on travaille en équipe.]
, mais d’utiliser des outils dédiés (cf. [Outils]).

Pour ceux qui cherchent à étudier un diagramme en particulier voici un plan de cette section (nous utilisons ici le "plan" vu lors de l’introduction de la [Matrice]) :

Table 2. Organisation
Requirements, cf. [reqs] Structure, cf. [archi] Comportement, cf. [behavior] Transverse, cf. [transvers]

Organisation

pkg

pkg, bdd

pkg

Analyse, Conception, Implémentation
[En fonction du niveau de détail.]

req

bdd, ibd, sd, par

uc, sd, stm, act

par

3. Outils SysML

Il existe un certain nombre d’outils permettant de réaliser des modèles SysML. Voici une liste non exhaustive :

Vous trouverez sur Internet des comparatifs et des avis à jour sur les outils.

Ce que je voudrai souligner ici c’est l’importance du modèle comme "dépôt" (je préfère le terme anglais de repository) d'éléments de base en relation les uns avec les autres. C’est toute la différence entre le dessin et le modèle.

Caution

Attention toutefois à ne pas confondre ce que vous permet (ou pas) de faire l’outil et la notation elle-même. Les fabricants ont parfois pris des libertés ou bien n’ont pas complètement implémenté toutes les subtilités de la notation.

4. Cadre pour les diagrammes

Abordons quelques principes généraux de SysML, c’est à dire des éléments indépendant d’un diagramme en particulier :

  • Chaque diagramme SysML représente un élément de modélisation

  • Chaque diagramme SysML doit être inclus dans un cadre (Diagram Frame)

  • L’entête du cadre, appelé cartouche, indique les informations sur le diagramme :

    • le type de diagramme (req, act, bdd, ibd, stm, etc.)

    • le type d'élément (package, block, activity, etc.)

    • le nom de l'élément

    • le nom du diagramme ou de la vue

Dans l’exemple ci-dessous, le diagramme "Context_Overview" est un Block Definition Diagram (type bdd) qui représente un package, nommé "Context".

images/pacemaker-context.png
Figure 20. Exemple de diagramme SysML

5. Organisation

Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

5.1. Fondements

On abordera :

  • Le Package Diagram

  • Les différent types de packages

  • Les organisations possibles

  • La notion de Namespaces

  • Les Dependencies

5.2. Le Package Diagram

Le diagramme de paquetage permet de représenter l’organisation des modèles en paquetages.

  • Il est identique à UML, et classique pour les développeurs (java notamment)

  • Il permet d’organiser les modèles en créant un espace de nommage (cf [namespace])

Les modèles peuvent être organisés selon toutes sortes de considération (cf. [organisation]) :

  • hiérarchie "système" (e.g., entreprise, système, composant)

  • types de diagrammes (e.g., besoins, structure, comportements)

  • par points de vue

  • etc.

5.3. Les différent types de packages

Il existe plusieurs types de package :

models

un package "top-level" dans une hiérarchie de packages

packages

le type le plus classique : un ensemble d'éléments de modèles

model librairies

un package prévu pour être réutilisé (importé) par d’autres éléments

views

un package spécial pour représenter les points de vue

Tip

Un point de vue (viewpoint) est utilisé pour matérialiser une perspective particulière de modélisation. Il possède des propriétés standardisés (concerns, language, purpose, etc.) et permettent d’indiquer qu’une vue (un packetage particulier, stéréotypé <<view>>) est conforme (dépendance <<conform>>) à un point de vue.

5.4. Les organisations possibles

Les modèles peuvent être organisés selon toutes sortes de considération :

  • par hiérarchie "système" (e.g., entreprise, système, composant, …)

  • par types de diagrammes (e.g., besoins, structure, comportements, …)

  • par cycle de vie (e.g., analyse, conception, …)

  • par équipes (e.g., architectes, [IPT], …)

  • par points de vue (e.g., sécurité, performance, …)

  • etc.

images/pkg-organisation2.png
Figure 21. Exemple d’organisation simple
images/pkg-organisation-modelview.png
Figure 22. Représentation de cette organisation dans un outil
images/pkg-organisation.png
Figure 23. Un autre exemple d’organisation
images/pkg-topcased.png
Figure 24. Un autre exemple d’organisation
Tip

L’outil TOPCASED propose, lors de la création d’un premier modèle, de créer une organisation "type" par défaut.

images/pkg-template.png images/pkg-topcased-default.png

5.5. La notion de Namespaces

Un package permet de créer un espace de nommage pour tous les éléments qu’il contient. Ainsi, dans un package, on n’a pas à se soucier des noms des éléments. Même si d’autres utilisent les mêmes noms, il n’y aura pas ambiguité.

Note
Définition : Namespace (OMG SysML v1.3, p. 23)

The package defines a namespace for the packageable elements.

Pour éviter toute ambiguité, on peut utiliser pour les éléments de modèles leur nom complet (Qualified name), c’est à dire le nom de l'élément préfixé par son (ou ses) package(s) (e.g., Structure::Products::Clock).

Tip

Dans les outils SysML, il faut souvent demander explicitement à voir les noms complets (Qualified names) des éléments (la plupart du temps dans les options graphiques).

5.6. Les dépendances

Un certain nombre de dépendances peuvent exister entre des éléments de package ou entre les packages eux-mêmes :

Dependency

une dépendance "générale", non précisée,
représentée par une simple flèche pointillée ----->

Use

l'élément "utilise" celui à l’autre bout de la flèche (un type par exemple),
représentée par le stéréotype <<use>>

Refine

l'élément est un raffinage (plus détaillé) de celui à l’autre bout de la flèche,
représentée par le stéréotype <<refine>>

Realization

l'élément est une "réalisation" (implémentation) de celui à l’autre bout de la flèche,
représentée par le stéréotype <<realize>>

Allocation

l'élément (e.g., une activité ou un requirement) est "alloué" sur celui à l’autre bout de la flèche (un block la plupart du temps),
représentée par le stéréotype <<allocate>>

5.7. En résumé

SysML propose un certain nombre de mécanismes pour organiser les différents modèles, tirés pour la plupart d’UML. Ces mécanismes seront plus faciles à comprendre au travers de leur utilisation concrète dans la suite.

Table 3. Organisation
Requirements Structure Comportement Transverse

Organisation

package

package

package

dependencies

5.8. Questions de révision

  1. Quels sont les 5 types de dépendances entre packageable elements ?

  2. À quoi cela peut-il servir de définir les dépendances (donnez des exemples concrets) ?

6. Les exigences

Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

6.1. Fondements

On abordera :

  • L’organization des Requirements

  • Les Requirements properties

  • Les Requirements links

  • Les Requirements Diagrams

  • Les considérations sur la traçabilité

  • Annotations des Requirements

  • Les Use Case Diagrams (scénarios)

Tip

L’ingénierie des exigences est une discipline à part entière et nous n’abordons ici que les aspects en lien avec la modélisation système. Voir le livre de référence pour plus de détails ([Sommerville1997]) ou le guide de l’AFIS ([REQ2012]).

6.2. L’organisation des Requirements

Il ne s’agit pas ici de revenir sur les exigences elles-même, mais plutôt de voir comment SysML permet de les exprimer, de les manipuler et surtout de les lier avec le reste du système.

6.2.1. Différents types d’organisation

L’ingénierie des exigences aboutit généralement à une liste organisée d’exigences, que ce soit en terme de fonctionnelles/non fonctionnelles, de prioritaires/secondaires, etc. Le principal support de SysML à cette organisation, outre la possibilité de les annoter (cf. section Stéréotyper les exigences), consiste à utiliser les packages.

Plusieurs types d’organisations sont possibles :

  • Par niveau d’abstraction

    • Besoins généraux (en lien avec les use cases par exemple)

    • Besoins techniques (en lien avec les éléments de conception)

  • Par point de vue

    • Besoins principaux (en lien avec les use cases)

    • Besoins spécifiques :

      • Fonctionnels

      • Marketing

      • Environnementaux

      • Business

  • etc.

6.2.2. Tableaux de Requirements

Les requirements sont habituellement stockés dans des tableaux (feuilles excel le plus souvent!). Il est donc recommandé par le norme et possible dans de nombreux outils de représenter les exigences sous forme tabulaire.

Note
Définition : Namespace (OMG SysML v1.3, p. 145)

The tabular format is used to represent the requirements, their properties and relationships…

images/req-table.png
Figure 25. Exemples tableau d’exigences
images/req-modelio.png
Figure 26. Import Modelio de tableau d’exigences

6.3. Les Requirements properties

Il est possible d’indiquer un certain nombre de propriétés sur un requirement :

  • priority (high, low, …)

  • source (stakeolder, law, technical, …)

  • risk (high, low, …)

  • status (proposed, aproved, …)

  • verification method (analysis, tests, …)

Les principales relations entre requirement sont :

Containment

pour décrire la décomposition d’une exigence en plusieurs sous-exigences (⊕–)

Refinement

pour décrire un ajout de précision (<<refine>>)

Derivation

pour indiquer une différence de niveau d’abstraction (<<deriveReqt>>), par exemple entre un système et un de ses sous-systèmes

Tip

Lorsqu’un cas d’utilisation possède plusieurs cas <<refine>> qui pointent vers lui, on considère que ces différents cas sont des options possibles de raffinement (cf. [conventions]).

images/req-exp1.png
Figure 27. Exemples de relations entre exigences

Il existe ensuite les relations entre les besoins et les autres éléments de modélisation (les block principalement) comme <<satisfy>> ou <<verify>>, mais nous les aborderons dans la partie transverse.

images/topcased-req-connections.png
Figure 28. Relations liées au requirements dans TOPCASED

6.5. Les Requirements Diagrams

Voici un exemple de req un peu plus étoffé, tiré de http://www.uml-sysml.org/sysml (voir aussi [rationale]) :

images/hsuv-reqs1.png
Figure 29. Exemples de composition d’exigences

6.6. Stéréotyper les Requirements

Tout comme pour n’importe quel bloc, il est possible de stéréotyper les requirements. Ceci permet de se définir ses propres priorités et classifications. Quelques exemples de stéréotypes utiles :

  • <<interfaceRequirement>>, <<physicalRequirement>>, …

  • <<FunctionalRequirement>>, <<nonFunctionalRequirement>>

6.7. Annotations des Requirements

Il est possible d’annoter les éléments de modélisation en précisant les raisons (rationale) ou les éventuels problèmes anticipés (problem).

images/hsuv-reqs2.png
Figure 30. Exemples de rationale et problem

6.8. Les considérations sur la traçabilité

Une fois que les requirements ont été définis et organisés, il est utile de les lier au moins aux use cases (en utilisant <<refine>> par exemple) et aux éléments structurels (en utilisant <<satisfy>> par exemple), mais ceci sera abordé dans la partie [transvers].

Note

En général chaque requirement devrait être relié à au moins un use case (et vice-versa!).

6.9. Les Use Case Diagrams (scénarios)

Bien que nous traitions les cas d’utilisation dans la partie comportement, nous les abordons ici du fait de leur proximité avec les requirements.

images/req-uc-relation.png
Figure 31. Exemple de lien entre use case et requirements

Ce diagramme est exactement identique à celui d’UML.

images/UCGestionNotes.png
Figure 32. Exemple de diagramme des cas d’utilisation
images/uc.png
Figure 33. Autre exemple de diagrammes des cas d’utilisation
Tip

Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs.

6.10. En résumé

Les exigences sont très importantes en ingénierie système, plus en tout cas qu’en ingénierie logiciel, du fait de la multiplication des sous-systèmes et donc des intermédiaires (fournisseurs, sous-traitants, etc.) avec qui les aspects contractuels seront souvent basés sur ces exigences. Il n’est donc pas étonnant qu’un diagramme et des mécanismes dédiés aient été prévus en SysML.

Table 4. Déclinaison des Exigences
Requirements Structure Comportement Transverse

Organisation

⊕–, <<deriveReqt>>

Analyse

<<satisfy>>, <<refine>>

<<satisfy>> entre reqs et UC

<<refine>>

Conception

<<allocate>>

Implémentation

<<satisfy>>, <<verify>>

En terme de démarche, il est classique d’avoir de nombreux aller-retour entre la modélisation des exigences et la modélisation du système lui-même (cf. [sysmod]).

Figure 34. Exemple de démarche (SYSMOD Zigzag pattern)

6.11. Questions de révision

  1. Quelles sont les différences entre besoins et exigences ?

  2. En quoi les cas d’utilisation sont-ils complémentaires des exigences?

  3. Quelle est la différence entre un package de type model et un package de type package?

7. L’architecture du système

Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

7.1. Fondements

On abordera :

  • l’organisation du système et des modèles

  • les Block Definition Diagrams

  • les Internal Block Diagrams

  • les Parametric Diagrams (pour les contraintes physiques)

  • les Sequence Diagrams (diagramme de séquence système)

7.2. Organisation du système et des modèles

En terme d’organisation, le mécanisme clef est celui de package. Celui-ci va permettre d’organiser les modèles, pas le système lui-même. Nous avons abordé cette organisation (cf. [package]).

Pour l’organisation du système, on trouve le plus souvent :

  • un diagramme décrivant le contexte (le système dans son environnement), décrit dans un block definition diagram (cf. [contextebdd])

  • un diagramme décrivant les éléments internes principaux du système, décrit dans un internal block diagram

7.3. Block Definition Diagrams

7.3.1. Principes de base

Un bdd peut représenter :

  • un package

  • un bloc

  • un bloc de contrainte (constraint block)

Un diagramme de bloc décrit les relations entre les blocs (compositions, généralisations, …). Ce diagramme utilise les mêmes éléments que le diagramme de classe UML.

images/pacemaker-context.png
Figure 35. bdd du système dans son environnement

Un bloc est constitué d’un certain nombre de compartiments (Compartments) :

Properties

Equivalent UML des propriétés (e.g., attributs).

Operations

Les méthodes supportées par les instances du bloc.

Constraints

Les contraintes (cf. [contraintes])

Allocations

Les allocations (cf. [transvers])

Requirements

Les exigences liées à ce bloc.

User defined

On peut définir ses propres compartiments.

images/constraints.png
Figure 36. Exemple de définition de contraintes

7.3.2. Propriétés

On peut différencier 4 types de propriétés d’un bloc :

value properties

Des caractéristiques (quantifiables), aussi appelées simplement values

parts

Les éléments qui composent le bloc (cf. [ibd])

references

Les éléments auquel le bloc a accès (via des associations ou des agrégations)

constraint properties

Les contraintes que doivent respecter les propriétés (nous les verrons plus en détail, cf. [param]).

Note

Les values sont ce qui se rapproche le plus des attributs de classes UML.

7.3.3. Value Types

Pour associer un type aux valeurs, SysML propose de définir des Value Types.

images/valueType.png
Figure 37. Définition de Value Types.

7.3.4. Associations entre blocs

Il existe deux types de relations entre blocs :

  • l’association (y compris l’agrégation et la composition)

  • la généralisation/spécialisation

Ces deux types de relations, bien connues en UML, permettent de matérialiser les liens qui existent entre les éléments du système. Avant d’aborder les associations, il est important de différencier la description d'éléments structurels sous la forme d’un bloc (au travers d’un bdd par exemple) et ces éléments pris individuellement. Ces derniers sont des instances individuelles du même bloc. Cette notion, très présente dans les approches orientées objets est souvent plus ardue à appréhender pour les ingénieurs systèmes. Il faut bien comprendre que la modélisation d’un bloc consiste à représenter l’ensemble des éléments qui caractérisent tout une série d’objets (des moteurs, des pompes, des données, etc.). Il serait fastidieux de les représenter tous (individuellement), et c’est donc leur "signature" que l’on représente. C’est pour cela qu’un bloc n’est pas un élément physique, mais simplement sa représentation, tandis qu’une instance de ce bloc représentera elle cet élément physique. C’est le cas notamment des participants d’un diagramme de séquence ou encore des parties d’un composé, qui sont des instances et non des blocs.

Association

Une association est un ensemble de liens permanents existant entre les instances de deux ou plusieurs blocs. On dira qu’une association lie plusieurs blocs ou que les blocs participent à l’association.

Une association possède plusieurs propriétés :

Dimension d’une association

Nombre de blocs mis en jeu par l’association
(binaire : 2, ternaire : 3, n-aire : n)

Note
Exemple d’association binaire

Soient les bloc Fournisseurs et Produits. On veut indiquer quels sont les produits susceptibles d’être fournis par chaque fournisseur et quels sont les fournisseurs susceptibles de fournir chaque produit.

/Users/bruel/dev/asciidoc/ACSI/images/prod-fourn.png

Nom d’une association

Afin de clarifier les informations, il est important de nommer les associations.
Il existe trois façons de nommer une association :

  • un verbe à l’infinitif (e.g., Fournir)

  • un verbe conjugué avec un sens de lecture : Fournit > ou < Est fourni par

  • un rôle (placé à une extrémité de l’association)

Cardinalité

Indique à combien d’instances minimum et maximum du bloc d’en face est lié toute instance du bloc de départ. Elle est représentée par un couple (M..N).

Caution

Attention, dans une cardinalité M..N, M doit toujours être inférieur ou égal à N. Exemple : 3..10.

Vers le code : que signifie vraiment une association?

En terme de logiciel, une association représente une contrainte sur la suite du développement : que ce soit un code (en langage orienté objet la plupart du temps) ou une base de donnée.

Pour reprendre l’exemple précédent, cela signifie concrètement au niveau d’un code par exemple que depuis une variable Produits on doit être capable d’accéder à une variable (correspondante) de type tableau (ou liste, ou …) de Fournisseurs.

Ce qui peut donner en java :